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RESPONSE 

In response to the Final Office Action mailed March 21, 2008, please amend the 
above-identified application as follows: 

Amendments to the Claims: begin on page 2 of this paper. 
Remarks/Arguments: begin on page 9 of this paper. 
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Amendments to the Claims: 

This listing of claims will replace all prior versions, and listings, of claims in the application: 
Listing of Claims: 

1. (ciuTently amended) In a communications-networking environment, a 
method for automatically presenting the progress ot a transaction, comprising: 



receiving a transaction that requires completing one or more substeps 
wherein a substep is a process to be performed in an execution of the transaction; 
and 

without user interaction, conmiunicating to one or more display devices 
one or more indications respectively related to said one or more substeps as said 
one or more substeps are performed wherein comm unicating to the one or more 
display devices comprises communicating the one or more indications to a 
broadcasting device and sending the one or more indications from the 
broadcasting device to the one or more display devices. 

2. (previously presented) The method of claim 1, wherein said 



transaction includes two or more of the following: 

modifying call-routing instructions associated with a telecommunications 
network; 



implementing a database update; and 



implementing a LERG (Local Exchange Routing Guide) update; 
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3. (currently amended) The method of claim 2, wherein receiving a 

transaction includes suspending user control until said transaction is receive d, without user 
interaction, but prior to when said transaction is completed. 



4. (original) The method of claim 1, wherein communicating said one or 



more indications include communicating the indications to a device other than the device from 
which the transaction request was submitted. 



5. (currently amended) The method of claim 2, wherein communicating 



said one or more indications include connmimicating indications corresponding to disparate 
transactions to one or more display devices wherein disparate transactions are separate distinct 



indications respectively related to said me two or more substeps correspond to one or more of the 
following events: 



when a transaction is submitted; 
when a transaction is received; 
when a transaction is validated; 

when a transaction is accepted; 
when a transaction is reformatted; 

when a transaction is sent to one or more network devices; and/or 

when one or more messages from said one or more network devices are 



transactions . 



6. 



(previously presented) 



The method of claim 2, wherein said 



received. 
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7. (original) The method of claim 6, wherein said indications include a 
description of said respective event. 

8. (previously presented) One or more computer-readable storage 
media having computer-useable instructions embodied theieon for automatically providing real- 
time transaction-progression status updates, said method comprising: 

receiving a transaction, wherein the execution of the transaction involves 

performing one or more subprocesses; 

generating a plurality of status indicators as said one or more subprocesses 
progress; and 

dynamically communicating one or more of said plurality of status 
indicators to a broadcasting device, whereby said plurality of status indicators can 
be sent to one or more receiving components. 

9. (previously presented) The media of claim 8, wherein receiving a 
transaction includes receiving me two or more of the following: 

a database-update request; 
a table-modification request; 

a LERG (Local Exchange Routing Guide) update; and 
a network-device-configuration change. 

10. (original) The media of claim 9, wherein generating a plurality of 
status indicators include generating an indication of one or more of the following events: 

when a transaction is submitted; 
when a transaction is received; 
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when a transaction is validated; 
when a transaction is accepted; 
when a transaction is reformatted; 

when a transaction is sent to one or more network devices; and/or 
when one or more messages from said one or more network devices are 
received. 

11. (original) The method of claim 10, wherein said plurality of status 
indicators include a description of said respective event. 

12. (original) The method of claim 9, wherein dynamically 
communicating one or more of said plurality of status indicators are accomplished without user 

13. (currentiy amended) The method of claim 9, wherein dynamically 
communicating one or more of said plurality of status indicators include sending indicator(s) 
associated with unique transactions simultaneously wherein the unique transactions are separate 
distinct transactions . 

14. (currentiy amended) In a communications networking environment, a 
system for monitoring transaction progression in real time, the system comprising: 

a request-receiving component that receives an incoming transaction 
wherein said incoming- transaction includes two or more of the following: 

a caU-routing modification associated with a telecommunications network; 
a database update; 
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a LERG (Local Exchange Routing Guide) update; 

a table-modification request; and 

a network-device-configuration change; 

a status-monitoring component - coupled to said request-receiving 
component - that monitors the progression of said transaction and provides 
feedback related to the status of the transaction's progression toward completion; 

a status-transmission component for rocoiving that receives said feedback 
and oonrniunioating communicates said feedback to one or more receiving 
devices. 

15. (cancelled). 

16. (cuiTcntly amended) The system of claim 14, wherein said request 
receiving component retains processing control while receiving said incoming transaction but 
releases processing control , without user interaction, prior to final execution of said transaction. 

17. (original) The system of claim 16, wherein the status-monitoring 
component identifies a plurality of events that are accomplished as said transaction progresses 



18. (original) The system of claim 17, wherein the plurality of events 
include one or more of: 

submitting a transaction to process; 
receiving a transaction; 
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validating a transaction; 
accepting a transaction; 

sending a timsaction to one or more network devices; and 
receiving one or more responses from said network devices. 

19. (currently amended) A computer system having a processor and a 
memory coupled together for asynchionously monitoring network transactions in real time, the 
system comprising: 

a first user-interface component for submitting that submits one or more 
transaction requests; 

a transaction-processing system for receiving that receives said one or 
more transaction requests, monitoring monitors the transaction request(s) 
progression toward completion, and providing provides updates related to said 
progression; and 

a second user-interface component - which can be said first interface 
component - for receiving that receives said one or more updates and 
simultaneously pre s enting presents said updates, which can be related to separate 
distinct transactions. 

20. (original) The system of claim 19, wherein the transaction-processing 
system identifies a plurality of events that are accomplished as said transaction progresses 
toward completion. 

21. (original) The system of claim 20, wherein said second user-interface 
component presents said updates on a display device. 
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22. (original) The system of claim 21, wherein said second user-interface 
component includes functionality to view a historical log of said updates. 

23. (original) In a networking environment, a method for performing 
transaction updates asynchronously comprising: 

receiving from a user a request to execute one or more transactions; 
withholding processing control from said user while communicating said 

returning processing control to said user incident to completing 
communication of said one or more transactions to said transaction receiver but 
prior to the execution of said one or more transactions. 
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REMARKS 

Applicants respectfully request reconsideration of the present Application. 
Claims 1,3,5, 13-14, 16, and 19 have been amended herein. Claims 1-14 and 16-23 are pending 
and are in condition for allowance. 

Rejections based on 35 U.S.C. § 102fe) 

Claims 1, 8 and 19-23 were rejected under 35 U.S.C. § 102(e) as being anticipated 
by Conway, U.S. Publication No. 2003/0236777. 

Regarding claim 1, Conway does not teach "wherein communicating to the one or 
more display devices comprises communicating the one or more indications to a broadcasting 
device and sending the one or more indications from the broadcasting device to the one or more 
display devices ." Conway does not teach a broadcasting device that receives indications and 
then sends the indications to other devices. Therefore, Applicants respectfully request that the 
rejection of claim I be removed. 

Regarding claim 8, Conway does not teach the elements of claim 8. The same 
reasons traversing the rejection above for claim 1 are applicable here. Conway does not teach a 
broadcasting device that receives a plurality of status indicators and then sends the plurality of 
status indicators to receiving components. Therefore, Applicants respectfully request that the 
rejection of claim 8 be removed. 

Regarding claim 19, Conway does not teach "a first user-interface component", "a 
transaction-processing system" and "a second user-interface component" bundled into one 
computer system. Conway does not disclose a computer system with all of the elements of claim 
19. For example, a web page or web portal in Conway is not part of a computer system. 
Therefore, Applicants respectfully request that the rejection of claim 19 be removed. 
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For at least the above reasons, claims 20-22 depend from claim 19. Therefore, 
Applicants respectfully request that the rejection of claims 20-22 be removed. 

Regarding claim 23, Conway does not teach "withholding processing control 
from said user" nor "retuming processing control to said user". The same reasons traversing the 
rejections provided below for claims 3 and 16 are applicable here. Conway teaches that an end- 
user sends a transaction to a host to be processed. The host processes the transaction and returns 
the result to the end-user via the Internet. See paragraph [0007] in Conway. There is nothing in 
Conway that discloses withholding processing control. There is nothing in Conway that prevents 
the end-user from performing a second or third transaction after the first transaction is started. 
Applicants' claimed invention does not indicate any type of intervention. The broadest 
reasonable interpretation of claim 23 does not indicate any type of intervention 
(manual/user/extemal). Therefore, Applicants respectfully request that the rejection of claim 23 
be removed. 

Rejections based on 35 U.S.C. S 103(a) 

Claims 2-7 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Conway, U.S. PubUcation No. 2003/0236777 m view of Dugan et al., U.S. Patent No. 6,363,41 1. 

For at least the above reasons, claim 2 depends from claim 1. Therefore, 
Applicants respectfully request that the rejection of claim 2 be removed. 

Regarding claim 3, Applicants respectfully point out that the Office Action 
specifically rejects claim 3 on the grounds that user control is withheld until 
manual/user/extemal intervention is needed. However, the Office Action provides remarks to 
Applicants' arguments traversing the rejection of claim 3 by stating that "Conway teaches the 
capability of both automatic and manual execution." The Office Action further states "manual 
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intervention may not be necessary..." Applicants respectfully object to the inconsistent 
reasoning. The Office Action should not render a rejection of claim 3 on one hand stating 
manual intervention teaches claim 3, but dismisses Applicants' traversal of the rejection by 
stating there can be automatic execution. 

Further, regarding claim 3, Conway does not teach "receiving a transaction 
includes suspending user control until said transaction is received but prior to when said 
transaction is completed." Conway teaches that an end-user sends a transaction to a host to be 
processed. The host processes the transaction and returns the result to the end-user via the 
Internet. See paragraph [0007] in Conway. In addition, Conway teaches that if the host is 
unavailable or cannot complete the transaction due to issues other than unavailability, the 
transaction is not completed. Manual or external intervention is needed as the Examiner states in 
the Office Action. See paragraph [0012] in Conway. Consequently, the disclosure in Conway 
does not anticipate Applicants' claimed invention. First, there is nothing in Conway that 
discloses user control being suspended. The operative word is "suspending". The Examiner 
must give patentable weight to the term. There is nothing in Conway that prevents the end-user 
from performing a second or third transaction after the first transaction is started. Secondly, any 
use of manual intervention is inconsistent with claim 1 which requires "without user interaction". 
That requirement carries over to dependent claim 3. Conway discloses manual intervention 
which is contrary to Applicants' claimed invention. Thirdly, Conway discloses a transaction that 
is complete. When the results are returned to the end-user, this is evidence of a completed 
transaction. Applicants' claimed invention requires that user control only be suspended for a 
time before the completion of the transaction, not with the completion and not after the 
completion. Therefore, Applicants respectfully request that the rejection of claim 3 be removed. 
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For at least the above reasons, claim 4 depends from claim 1. Therefore, 
Applicants respectfully request that the rejection of claim 4 be removed. 

Regarding claim 5, Conway does not teach "communicating indications 
corresponding to disparate transactions to one or more display devices wherein disparate 
transactions are separate distinct transactions ." Conway discloses at paragraph [0037] "instant 
messages regarding the status and results of a transaction may be sent to the transaction agent or 
a wireless communication method may be used to update the transacting agent regarding the 
status and results of a transaction request. This language in Conway indicates that Applicants' 
claimed invention is not anticipated. Applicants' claimed invention requires communicating 
indications related to disparate transactions. Conway only discusses one transaction. Disparate 
transactions require separate distinct transactions. Conway does not disclose providing 
indications nor statuses pertaining to sepai'ate distinct transactions. Therefore, Applicants 
respectfully request that the rejection of claim 5 be removed. 

For at least the above reasons, claims 6-7 depends from claim 1. Therefore, 
Applicants respectfully request that the rejection of claims 6-7 be removed. 

Claims 9-14 and 16-18 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Conway, U.S. Publication No. 2003/0236777. 

For at least the above reasons, claims 9-12 depend from claim 8. Therefore, 
Applicants respectfiiUy request that the rejection of claims 9-12 be removed. 

Regarding claim 13, Conway does not teach "wherein the unique transactions are 
separate distinct transactions ." The reasoning provided above for claim 5 is applicable here. 
Applicants' claimed invention requires connmunicating status indicators related to unique 
transactions. Conway only discusses one transaction where instant messages are sent for one 
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transaction. Unique transactions equates to separate distinct transactions. Conway does not 
disclose providing indications nor statuses pertaining to separate distinct transactions. Therefore, 
Applicants respectfully request that the rejection of claim 13 be removed. 

Regarding claim 14, Conway does not teach "a status-transmission component 
that receives said feedback and commiimcates said feedback to one or more receiving devices." 
Therefore, Applicants respectfully request that the rejection of claim 14 be removed. 

Regarding claim 16, Conway does not teach the elements of claim 16. The same 
reasons traversing the rejection provided above for claim 3 are applicable here. There is nothing 
in Conway that discloses the request-receiving component retaining processing control whUe 
receiving an incoming transaction. The Office Action stated for independent claim 14 that the 
request-receiving component is Host 150 in Conway. As such. Conway does not disclose the 
Host 150 retaining processor control. Host 150 cannot be used to anticipate request-receiving 
component in the independent claim 14 and be totally ignored in dependent claim 16. Therefore, 
Applicants respectfully request that the rejection of claim 16 be removed. 

For at least the above reasons, claims 17-18 depend from claim 14. Therefore, 
Applicants respectfully request that the rejection of claims 17-18 be removed. 
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CONCLUSION 



For at least the reasons stated above, claims 1-14 and 16-23 are now in condition 
for allowance. Applicants respectfully request withdrawal of the pending rejections and 
allowance of the claims. If any issues remain that would prevent issuance of this application, the 
Examiner is urged to contact the undersigned - 816-474-6550 or lsearcv@shb.com (such 
communication via email is herein expressly granted) - to resolve the same. It is believed that 
no fee is due, however, the Commissioner is hereby authorized to charge any amount required to 
Deposit Account No. 21-0765. 

Respectfully submitted, 

/Leonard Searcy, L/ 

Leonard Searcy, n 
Reg. No. 53,574 

LS/bp 

SHOOK, HARDY & BACON L.L.P. 

2555 Grand Blvd. 

Kansas City, MO 64108-2613 

816-474-6550 
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